Oh wow. This is very nice!

I guess I should hold off on that 2.8.0 release and see if we can get this in.

Great! Thanks!

Hej @emilk

This is new to me. So when we now have a problem with duplicates: https://github.com/algesten/ureq/actions/runs/6361674777/job/17276257519

What do we do?

• Wait for it to sort itself out (when upstreams dep fix it)?
• Lock down our deps?

cargo tree -i is an invaluable tool to find the causes of duplicate dependencies.

Often you can solve it by strategically downgrading or upgrading some crates using cargo update -p $crate --precise $version.

Sometimes you need to make a PR to an upstream package, or poke their maintainer to release a new version.

For small duplicate dependencies you can add an exception in deny.toml

In this case I believe you can solve it with cargo update -p url --precise 2.3.1

This will update the versions in Cargo.lock, proving to cargo-deny that it is possible to build ureq without duplicate dependencies. Note that this does NOT prevent users of ureq from upgrading url to 2.4.1 again, and reintroducing that duplicate dependency (that is out of your hands, as it should be)

Perfect! Thanks for the explanation. I didn't know the cargo update commands for this, but I believe I did the same, manually in Cargo.toml.

Thanks!

You did this::

url = "=2.3.1"

which is NOT the same. This forces url 2.3.1 on all downstream users of ureq, meaning they cannot update url, even if 2.3.1 is shown to have some vulnerability fixed by e.g. 2.4

It is almost never the right choice to use = in a Cargo.toml version string - better to update just the Cargo.lock using cargo update -p url --precise 2.3.1

Right. So what you're saying is that we are only going to make the lock file have 2.3.1, which satisfies url = "2", but we're not going to help any consumer of ureq to avoid the double dep by locking down the version in toml?

Exactly - consumers will have to do a similar cargo update -p url --precise 2.3.1 if they also wanna avoid duplicate dependencies